Management of application access to directories by a hosted directory service

ABSTRACT

Features are disclosed for facilitating management of network directories of multiple organizations by a directory management system. Various applications can access the directories of the organizations via the directory management system according to the permissions that the applications have been granted by the respective organizations. Organizations may maintain directories on-premises or off-premises, and the applications can access the directories via the directory management system regardless of the physical location of the directories. Additionally, the applications may be hosted by a computing service provider that also hosts or otherwise manages the directory management service, or the applications can be hosted by third-party servers separate from the directory management system and the organizations.

PRIORITY CLAIM

This application is a continuation of U.S. application Ser. No.14/499,714, filed Sep. 29, 2014, the disclosure of which is herebyincorporated by reference.

BACKGROUND

Organizations, such as companies and other enterprises, often networktheir computing devices to communicate with each other and withcomputing devices outside of the organization. Network directories, alsoreferred to simply as “directories,” are specialized collections ofinformation about devices, applications, people and other common objectsof computer networks. Organizations with computing networks typicallyuse directories to efficiently locate, organize, administer andotherwise manage the network resources. For example, a user may be addedto a directory and associated with particular credentials. Thereafter,the user may be authenticated by comparing user-supplied credentials(e.g., obtained during a login procedure) to those in the directory.Information about what the user is authorized to do may then beretrieved from the directory. As another example, individual computers,printers and other devices that are part of a network environment may belisted in a directory, and applications or users may look up a list ofavailable devices in the directory and obtain information for accessingthem (e.g., names, addresses, etc.).

Some network-based service providers (e.g., providers of “cloud-based”services to external customers, such as file storage and backup,messaging, social networking, and the like) maintain their owndirectories and use those directories in part to provide authenticationservices to third party applications and services. Customers and otherusers create accounts with the network-based service providers andobtain user credentials. Users can then log onto various third partyapplications and services using the credentials associated with thenetwork-based service provider, and the network-based service providercan authenticate the user without exposing the user's secure information(e.g., password) to the third party applications and services.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments of various inventive features will now be described withreference to the following drawings. Throughout the drawings, referencenumbers may be re-used to indicate correspondence between referencedelements. The drawings are provided to illustrate example embodimentsdescribed herein and are not intended to limit the scope of thedisclosure.

FIG. 1 is a block diagram of an illustrative network environmentincluding a computing service provider and various organizations,applications, and users according to some embodiments.

FIG. 2 is a diagram of a user interface for managing application accessto directories according to some embodiments.

FIG. 3 is a flow diagram of an illustrative process for managingapplication access to directories.

FIG. 4 is a diagram of illustrative interactions and data flows betweena network-based directory service and a user, application, andorganization.

FIG. 5 is a diagram of additional illustrative interactions and dataflows between a network-based directory service and a user, application,and organization.

DETAILED DESCRIPTION Introduction

The present disclosure involves an architecture in which a directoryservice that is separate from enterprises and other organizationalcustomers (e.g., a cloud-based or other remote directory service) canfacilitate the use of the customers' own directories to access, interactwith, and otherwise use applications that are also separate from thecustomers. The directory service can manage access to the directories ofmultiple (e.g., two or more) customers by applications that may beassociated with the directory service, or by third-party applicationsseparate from both the directory service and the customers.

Some conventional directory service providers offer authenticationservices to third-party applications, and the applications may beauthorized to access certain directory information. For example, asocial network may maintain a directory of users in which user logincredentials, contact information, and other information associated withthe users is stored. The social network may provide login andauthentication services to third-party applications, thereby allowingusers to log in to multiple applications using a single set of logincredentials without worrying about unauthorized exposure of theirpasswords and other information to the other applications. In addition,the social network (with authorization from users) may allow thethird-party applications to access certain directory information, suchas information about the users' contacts, access to user-specificportions of the social network, etc. However, such conventionaldirectory services do not integrate with multiple, separate customerdirectories; rather, they typically maintain their own directories.Thus, users wishing to use such conventional directory services mustcreate new accounts and obtain new login credentials rather thanleveraging their own existing accounts, login credentials, and otherdirectory information (e.g., directory information from a directorymanaged by the enterprises for which the users work).

Some aspects of the present disclosure relate to systems that manageaccess to the directories of multiple (e.g., two or more) differentcustomers by applications remote from the customers. Individualcustomers (e.g., enterprises and other organizations) may configureaccess to their own directories through a network-based directoryservice that services multiple customers. In some embodiments, thenetwork-based directory service may provide an interface with whichcustomers may configure application access to the customers'directories. For example, a customer may access a web-based interface,hosted by or generated by the network-based directory service. Thecustomer may select individual applications that are configured to useor are otherwise compatible with the network-based directory service.The customer can then selectively authorize one or more of theapplications to access the customer's directory and authorize theapplications to perform other directory-related actions. Illustratively,the directory-related actions that customers may authorize applicationsto perform may include, among other things: creating, modifying, and/ordeleting users; creating, modifying, and/or deleting groups of users;managing passwords; listing users; authenticating users; joiningcomputers to domains; creating, modifying, reading, writing, anddeleting files; modifying file storage structures; and the like. In someembodiments, a customer may have multiple directories, and can authorizeapplication access and/or assign permissions on a directory-by-directorybasis. In additional embodiments, a customer may have multiple groups ofusers or other objects within a given directory, and the customer canauthorize access and/or assign permissions on a group-by-group basis.

Additional aspects of the present disclosure relate to managing theaccess that applications have to directories of particular customers,whether those directories are on-premises directories or off-premisesdirectories. Individual customers may have directories on their ownpremises (e.g., stored on servers physically present on, or proximateto, their premises) or off-premises (e.g., stored on servers physicallyremote from the customer premises, such as a data center of anetwork-based directory service or other computing service provider). Inorder to support both types of customers, the network-based directoryservice may implement application programming interfaces (“APIs”) and/orother system components that allow applications to access, modify, andotherwise use customer directories regardless of whether they areon-premises or off-premises (with respect to the customer). Thus, asingle network-based directory service may facilitate access by anynumber of applications to the directories of any number of customers,regardless of the physical location of the directories. Such anetwork-based directory service is more flexible than a traditionalnetwork-based directory service that maintains its own directory foraccess by applications, or directory services which provide access tothe directory of only a single customer. In some embodiments, the accesspermissions that organizations are permitted to provide to applicationswith respect to on-premises directories may be identical to the accessprovided to applications with respect to off-premises directories, whilein other embodiments the access permissions that organizations arepermitted to provide with respect to on-premises directories may bedifferent than off-premises directories.

Although aspects of the embodiments described in the disclosure willfocus, for the purpose of illustration, on specific examples andembodiments of applications, directories, directory services, andnetwork-based computing service providers, one skilled in the art willappreciate that the examples and techniques disclosed herein areillustrative only and may be applied to any number of services, process,or applications. Various aspects of the disclosure will now be describedwith regard to certain examples and embodiments, which are intended toillustrate but not limit the disclosure.

Example Network Environment

FIG. 1 shows an example network environment in which directorymanagement features of the present disclosure can be implementedaccording to some embodiments. As used herein the term “directory”generally refers to an organized collection of data about users,devices, applications, and other common resources of a computer network.Each resource on a computer network (or some subset thereof) may berepresented as an object in a directory, and information about aparticular resource (e.g., name, address, permissions, etc.) can bestored as attributes of that object. Information can be securely storedwithin or in association with the object such that only users withsufficient permissions are able to access, modify, or otherwise use theinformation. As used herein, the term “permissions” general refers tosecurity clearance, access rights, policies, and other forms ofauthorization that may be granted to users, devices, applications, andservices. Such permissions often indicate, among other things: whichcomputing resources (represented by objects in a directory) can beaccessed, modified, created, deleted, or used; which network-related ordirectory-related actions may be performed; and the like.

As shown, the network environment includes various user devices 102, acomputing service provider 104, organizations 106 and third-partyapplication servers 108 in communication via one or more networks 110.The computing service provider 104 can provide applications, directorymanagement services, and/or other network-based services to variousorganizations or other customers. Organizations 106A-106C (or othercustomers) can employ the computing service provider 104 to provideapplication access to users associated with the organizations, managethe organizations' directories, etc. Individual users can use computingdevices 102 to access applications hosted by the computing serviceprovider 104 (or third-party application servers 108) using credentialsfrom their respective organizations 106A-106C. In addition, thecomputing service provider 104 can provide the applications with accessto the directories of the various organizations 106A-106C at thediscretion of the respective organizations, as described in greaterdetail below.

The user computing devices 102 can correspond to a wide variety ofcomputing devices, including desktop computing devices, laptop computingdevices, terminal devices, mobile phones, tablet computing devices,media players, wearable computing devices (e.g., smart watches, smarteyewear, etc.), and various other electronic computing devices andappliances having one or more computer processors, computer-readablememory and network-access capabilities. Some user computing devices 102may be associated with a particular organization 106A-106C. For example,an organization may have various user computing devices 102 that remainon-premises, or that are used off-premises primarily by employees orother users associated with the organization. In some embodiments, someor all of the user computing devices 102 may be separate from anyorganization, such as public computers or home computers that are usedby any number of users to perform various tasks, which may includeaccessing applications using credentials associated with a particularorganization 106A-106C or other customer of the computing serviceprovider 104.

The computing service provider 104 can be a computing system configuredto host or otherwise provide access to applications 140, managedirectories for separate customer organizations 106A-106C, and/orprovide other network-based services and resources. For example, thecomputing service provider 104 can be a server or group of servers thatmay be accessed via a communication network 110. The computing serviceprovider 104 can include a number of components to provide variousfeatures described herein, such as one or more applications orapplication servers 140 and a directory management system or service 142that can be accessed by organizations 106 and user computing devices102. The computing service provider 104 may also store variousoff-premises directories 144, such as an off-premises directory fororganization 160B, as described below. The computing service provider104 may also include various data stores, such as an application accessdata store 146 to store metadata regarding the directories that can beaccessed by applications 140 within the computing service provider 104and/or applications on third-party application servers 108. In someembodiments, the computing service provider 104 may include additionalor fewer components than illustrated in FIG. 1.

As used herein, the term “off-premises directory” refers to a directorythat is remote from the organization with which it is associated, inorder to distinguish such a directory from a directory that is locatedon an organization's premises. Thus, although a directory may bephysically stored on the premises of a computing service provider 104,the directory may nevertheless be referred to as an off-premisesdirectory because it is off-premises with respect to the organizationwith to which it belongs (e.g., the organization that owns or operatesthe network described by the directory). Additionally, although adirectory may be physically stored off the premises of the computingservice provider 104, the directory may nevertheless be referred to asan on-premises directory because it is on-premises with respect to theorganization to which it belongs.

The computing service provider 104 may be a single computing device, orit may include multiple distinct computing devices, such as computerservers, logically or physically grouped together to collectivelyoperate as a server system. The components of the computing serviceprovider 104 can each be implemented as hardware, such as a servercomputing device, or as a combination of hardware and software. Inaddition, the components of the computing service provider 104 can becombined on one server computing device or separated individually orinto groups on several server computing devices. In some embodiments,the features and services provided by the computing service provider 104may be implemented as web services consumable via the communicationnetwork 110. In further embodiments, the features and services areprovided by one more virtual machines implemented in a hosted computingenvironment. The hosted computing environment may include one or morerapidly provisioned and released computing resources, which computingresources may include computing, networking and/or storage devices. Ahosted computing environment may also be referred to as a cloudcomputing environment.

The organizations 106A-106C can correspond to various customers of thecomputing service provider 104. Although the term “organization” is usedherein, the features involving such organizations may additionally oralternatively involve any customer having a directory (whetheron-premises or off-premises) and wishing to use the computing serviceprovider 104 to manage access to the directory by applications hosted bythe computing service provider 104 or third-party application servers108.

Organizations that maintain on-premises directories 160 may have one ormore servers on which the directories 160 are stored. For example,organization 106A may have a data center that includes various servers,and an on-premises directory 160 may be stored on one or more of theservers. Organizations that maintain off-premises directories may employthe services of the computing service provider 104, which may store theoff-premises directory in an off-premises directory data store 144. Forexample, organization 106B may not maintain an on-premises directory atall, but may rely instead on the computing service provider 104 tomaintain the organization's directory 144. Some organizations may chooseto maintain multiple directories on-premises and/or off-premises. Forexample, organization 106C may store multiple on-premises directories160, each in a manner similar to organization 106A (described above),and the organization 106C may also choose to employ the computingservice provider 104 to maintain an off-premises directory 144. Thedirectory 144 maintained by the computing service provider 104 in thisexample may be a mirror or subset of the on-premises directory (e.g. forbackup or disaster-recovery purposes), or it may be a separate directoryaltogether (e.g., a directory of computing resources in a differentregion from the on-premises directory 160).

The communication network 110 may be a publicly accessible network oflinked networks, possibly operated by various distinct parties, such asthe Internet. In some embodiments, the communication network 110 may beor include the Internet, a private network, personal area network, localarea network, wide area network, cable network, satellite network,cellular telephone network, etc. or combination thereof.

Setting Up Application Access to Directories

FIG. 2 shows an example user interface for managing application accessto an organization's directory or directories. A system administrator orsome other user associated with an organization, such as one of theorganizations 106A-106C shown in FIG. 1, may access the computingservice provider 104 to manage application access to the organization'sdirectory. Illustratively, the computing service provider 104 mayinclude a server (e.g., a web server) that generates and transmitsnetwork-based content pages for managing directories and applications.The content page 200 shown in FIG. 2 is an example of such a contentpage.

The interface may include separate panels, areas or portions for showinginformation about the organization's directory and for configuringapplication access to the directory. For example, directory information202 may include the directory name, ID, size (e.g., number of users orother objects), type (e.g., on-premises or off-premises), date launched,address, description, status, applications and services enabled to usethe directory, etc.

An application authorization portion 204 may include a listing of allapplications and services with which the current directory may be used.As shown, the available applications may include applications hosted orotherwise managed by the computing service provider 104. In addition,applications hosted by third party servers 108 may access theorganization's directory through the computing service provider 104(e.g., via an API provided by the computing service provider 104), andmay also be listed in the application authorization portion 204. A usermay selectively authorize or de-authorize individual applications by,e.g., activating or de-activating a checkbox 206 or interacting withsome other interface control configured to indicate selection orde-selection of an item.

For applications that the user has chosen to authorize, the user maydetermine which permissions may be given to the application. A drop-downlist 208 or some other interface control configured to present multipleselectable options may be provided to allow the user to selectpermissions or otherwise authorize directory-related actions forindividual applications. In some embodiments, the directory-relatedactions that the applications may be authorized to perform include:creating, modifying, and/or deleting users; creating, modifying, and/ordeleting groups of users; managing passwords; listing users;authenticating users; joining computers to a domain; creating,modifying, and deleting files and file system objects; and the like.Permissions selected for some applications may be different than thoseselected for other applications. In some cases, a user may selectmultiple permissions for a single application, such as when theavailable options are not mutually exclusive (e.g., allowing a filestorage and backup application to modify user information and also joinnew computers to the domain with which the directory is associated). Infurther embodiments, for ease of administration, roles may be created(e.g., within the directory and/or at the computing service provider104) to encompass multiple directory-related actions. Applications maythen be assigned to one or more roles.

The options that are presented in the drop-down list 208 or otherwiseselectable for a particular application may be limited based on thepermissions granted to the directory management service 142 or thecomputing service provider 104 in general. When an organization employsthe computing service provider 104 to manage the organization'sdirectory (or portions thereof), the organization may not grant thecomputing service provider 104 complete authority to access and modifyall aspects of the directory. For example, organization 106A maymaintain an on-premises directory 160, and may create a user account orrole within the directory 160 that the organization 106A can assign tothe computing service provider 104. The user account or role may includepermissions to perform only a subset of all directory-related actionsthat may be performed on or with the directory, such as full authorityover some objects or object types, read-only access to other objects orobject types, no access to still other objects or object types, etc. Theuser account (or a user account assigned to the role) may then beprovided to the computing service provider 104 for use in accessing thedirectory 160. Thus, when the directory management service 142 of thecomputing service provider 104 accesses the on-premises directory 160 ofthe organization 106A on behalf of some application or service, thedirectory management service 142 may only perform the directory-relatedactions that have been authorized for the user account with which thedirectory management service 142 is accessing the directory 160.

The directory-related actions that may be performed by applications viathe directory management service 142 may be limited based on thepermissions granted to the directory management service 142 and also thepermissions granted to the respective applications. As described above,the directory management service 142 or the computing service provider104 in general may only be authorized to perform a subset of possibledirectory-related actions in a particular directory. When anorganization administrator or other user sets up application access tothe organization's directory, the permissions assigned to any particularapplication may not go beyond those granted to the directory managementservice 142. However, in some embodiments the user may “down-scope” thepermissions by granting less than the full set of permissions granted tothe directory management service 142. For example, the directorymanagement service 142 may be granted permission to read and modify useraccounts but not to create new user accounts. When a user is assigningpermissions to an application that will access the directory via thedirectory management service 142, the user may not be permitted to grantthe application permission to create new user accounts because thedirectory management service 142 itself cannot do so. However, the usermay restrict application access to user accounts beyond the restrictionsapplied to the directory management service 142 by, e.g., grantingread-only access to use information.

When an application is authorized access to a directory and assignedspecific permissions, data regarding the application and its permissionswith respect to the directory may be stored at the computing serviceprovider 104 so that the computing service provider 104 can quicklyimplement or otherwise facilitate the authorized access. For example,metadata may be stored in the application access data store 146indicating that a particular application, such as a file storage andbackup application, has access to the file systems of computing deviceswithin the organization's directory. Thereafter, when a user with logincredentials in the organization's directory logs in to the computingservice provider 104 and wishes to use an application, the computingservice provider 104 can determine which applications may access thedirectory, which directory-related actions the applications have beenauthorized to perform, etc. In some embodiments, applicationauthorization and permissions may be stored in the organization'sdirectory in addition to, or instead of, the application access datastore 146. For example, is the organization's directory is anoff-premises directory managed by the computing service provider 104,the application authorization and permissions may be stored in theoff-premises directory data store 144 with the rest of theorganization's directory information.

Managing Application Access to Directories

FIG. 3 illustrates a sample process 300 that may be used by a directorymanagement service 142 or some other module or component of a computingservice provider 104 to manage application access to customerdirectories. Advantageously, the directory management service 142 maymanage application access to directories of multiple, distinctorganizations or other customers, rather than a single directory of thedirectory management service 142. Moreover, in some embodiments thedirectories of the multiple, distinct organizations may be eitheron-premises directories, off-premises directories, or some combinationthereof. In this way, the directory management service 142 can provideconsistent directory access services to various applications regardlessof which organizations own the directories, the location of thedirectories, the format of the directories, etc.

The process 300 begins at block 302. For example, the process 300 maybegin automatically upon user initiation of a connection with thecomputing service provider 104 by launching a browser application on auser computing device 102 and navigating to a login page, by launching aclient application on the user computing device 102 that establishes aconnection with the computing service provider 104, etc.

At block 304, the computing service provider 104 can receive user logincredentials and information about the user's organization. The logincredentials may be provided by the user via a graphical interface (e.g.,text boxes provided for user name and password on a web page displayedby a browser application), or they may be automatically provided duringor subsequent to establishment of a connection between the usercomputing device 102 and the computing service provider 104. In someembodiments, the user's organization may be provided by the user via thegraphical interface (e.g., using a drop-down list), with the user'slogin credentials (e.g., pre-pended onto the user's username), or it maybe known by the computing service provider 104 if the user has accessedan organization-specific login page (e.g., using a network address thatincludes an identifier of the organization).

At block 306, the directory management service 142 or some other moduleor component of the computing service provider 104 can determine theparticular directory to use in authenticating the user, authorizingparticular actions, and otherwise proceeding with the user's session atthe computing service provider 104. The directory may be determinedbased on information provided with the user credentials. For example,the “user name” portion of the user's credentials may include anidentifier associated with a particular customer, a particular domain ofa customer, a particular directory, etc. In some embodiments, thedirectory may be determined based on the manner which the userestablished the session with the computing service provider 104. Forexample, the user may have accessed a login page using a uniformresource locator (“URL”) or other network address that is uniquelyassociated with a particular customer, a particular domain of acustomer, a particular directory, etc.

At block 308, the directory management service 142 or some other moduleor component of the computing service provider 104 can authenticate theuser and determine which applications the user is authorized to access.Any number of applications, whether hosted by application servers 140 ofthe computing service provider 104 or by third party application servers108, may be configured to work with the directory management servicer142. However, not all applications may be permitted to access thecurrent directory (determined above), and the current user may not bepermitted to access applications (even if particular applications arepermitted to access the current directory). The directory managementservice 142 may authenticate the user using the current directory andthe user-supplied (or automatically obtained) user credentials. Thedirectory management service 142 may then determine which applicationsthe user is permitted to access, and present a listing of availableapplications at block 310. In some embodiments, a user may select anapplication first and then log in to that application.

At decision block 312, the directory management service 142 or someother module or component of the computing service provider 104 candetermine whether the user has accessed a particular application. If so,the process 300 can proceed to block 314; otherwise, the process 300 canterminate.

At block 314, the directory management service 142 or some other moduleor component of the computing service provider 104 can determine theapplication-specific permissions for the selected or otherwise accessedapplication. As described above, the application-specific permissionsmay be stored in the application access metadata store 146. Thus, thedirectory management service 142 can determine the application-specificpermissions for the current application by querying or otherwiseaccessing data in the application access metadata store 146. In someembodiments, application-specific permissions may be stored in someother location, such as in the current directory (e.g., an off-premisesdirectory of the current customer), and the permissions can be obtainedfrom that location.

At block 316, the directory management service 142 or some other moduleor component of the computing service provider 104 can implement theapplication-specific permissions. Implementation of application-specificpermissions may include enabling or permitting the application toperform certain actions using the current directory, prohibiting theapplication from performing certain actions using the current directory,etc. FIGS. 4 and 5 show example interactions and data flows between thedirectory management service 142 and various user computing devices,applications and organizations to illustrate the implementation ofapplication-specific permissions.

FIG. 4 shows interactions between a user computing device 102, anapplication 140, an organization 106A, and the directory managementservice 142 during the process of setting up application access to thedirectory 160 and the subsequent management of directory access by thedirectory management service 142.

At (A), the application 140 may be registered with the directorymanagement service 142, which can store information about theapplication 140 in the application access metadata 146 at (B).Registration of an application 140 allows the directory managementservice 142 to set up permissions to the directories of variousorganizations (e.g., provide the application 140 as an option in theinterface shown in FIG. 2). The application information that is storedmay include, e.g., the application name, logo, description, technicalinformation, and the like. In some embodiments, the applicationdeveloper or host may register the application 140 with the directorymanagement service 142. In other embodiments, the directory managementservice 142 (or an administrator, technician, or other person associatedtherewith) may register the application 140.

At (C), the organization 106A may set up application permissions to theorganization's on-premises directory 160. In some embodiments, anadministrator, technician, or other person associated with theorganization may use the interface 200 described above with respect toFIG. 2. For example, the application 140 may be file storage and back upapplication hosted by the computing service provider 104. Theapplication 140 may require substantial permissions in order to providethe full scope of its functionality to the organization 106A, includingpermission to access and modify the file system of the organization'scomputers, permission to join computing devices (e.g., storage servers)to the organization's domain, etc. These and other permissions may begranted to the application 140 individually, or through the assignmentof a particular role or other policy to the application. At (D), thedirectory management service 142 can store metadata about thepermissions granted to the application 140 in the application accessdata store 146.

At (E), a user may use a user computing device 102 to log in to thecomputing service provider 104. Illustratively, the user may be anemployee of the organization 106A, and may use credentials supplied bythe organization. At (F), the directory service provider 142 can use thedirectory 160 to authenticate the user and determine which applicationsthe user may access or otherwise determine what the user is authorizedto do. In the present example, the user may be authorized to access thefile storage and backup application 140, and at (G) the user may launchthe application in order to access some previously stored file, change abackup protocol, or the like.

At (H), the directory management service 142 can determine whichpermissions the application 140 has with respect to the organization'sdirectory 160. As described above, the application 140 may havesubstantial permissions in order to facilitate implementation of thefull scope of the functionality provided by the application 140. Thus,the application 140 may perform actions at (I) that involve substantialdirectory permissions because the application 140 has been granted suchpermissions, and information pertaining to the granted permissions hasbe stored in, and retrieved from, the application access data store 146.In some embodiments, the application 140 may not necessarily permitusers to request performance of all actions that the application 140 hasbeen authorized to perform. Instead, the application 140 may down-scopethe permissions for the current user, instead allowing the user toinitiate only a subset of actions. For example, if the current user isnot a file storage and backup specialist or is otherwise not part of theinformation technology (IT) department of the organization 106A, theuser may not be permitted to initiate actions that the application 140is otherwise authorized to perform. Such down-scoping of permissions maybe based on permissions granted to the user in the directory 160. Forexample, any given user may only initiate actions using any givenapplication that both the user and the application are authorized by theorganization to perform.

FIG. 5 shows interactions between a user computing device 102, anorganization 106B, an application 180 hosted by a third-party server108, and the directory management service 142. The illustratedinteractions may occur during the process of setting up applicationaccess to an off-premises directory of the organization 160B and duringthe subsequent management of directory access by the directorymanagement service 142.

At (1), the application 180 may be registered with the directorymanagement service 142, which can store information about theapplication 180 at (2), as described above with respect to FIG. 4. At(3), the organization 106B may set up application permissions to theorganization's off-premises directory 160. In some embodiments, anadministrator, technician, or other person associated with theorganization may use the interface 200 described above with respect toFIG. 2. For example, the application 180 may be a messaging applicationhosted by a third-party server 108. The application 108 may only requirea moderate level of permissions in order to provide the full scope ofits functionality to the organization 106B, such as read-only access tousers' contact information. As described above, permissions may begranted to the application 108 individually, or through the assignmentof a particular role or other policy to the application. At (4), thedirectory management service 142 can store metadata about thepermissions granted to the application in the application access datastore 146.

At (5), a user may use a user computing device 102 to log in to thecomputing service provider 104. Illustratively, the user may be anemployee of the organization 106B, and may use credentials supplied bythe organization. At (6), the directory service provider 142 can use theoff-premises directory of the organization 106B, stored in theoff-premises data store 144 or in some other location, to authenticatethe user and determine which applications the user may access orotherwise determine what the user is authorized to do. In the presentexample, the user may be authorized to access the messaging application180, and at (7) the user may launch the application 180.

At (8), the directory management service 142 can determine whichpermissions the application 180 has with respect to the organization'soff-premises directory. As described above, the application 108 may havemoderate permissions, such as read-only access to user contactinformation. Thus, the application 180 may perform actions at (9) thatinvolve the moderate directory permissions.

Each of the examples illustrated in FIGS. 4 and 5 may be facilitated bya single directory management service or system. The examples shown anddescribed herein are illustrative only, and are not intended to belimiting. As will be appreciated, additional examples may also befacilitated by the same directory management system, such as managementof access to multiple directories of a single organization, managementof access to directories by various other types of applications, etc.Because the directory management service can manage access, byintegrated or third-party applications, to directories of multipleorganizations, whether on-premises or off-premises, the directorymanagement service can provide a flexible solution to a wide range oforganizations.

Terminology

Depending on the embodiment, certain acts, events, or functions of anyof the processes or algorithms described herein can be performed in adifferent sequence, can be added, merged, or left out altogether (e.g.,not all described operations or events are necessary for the practice ofthe algorithm). Moreover, in certain embodiments, operations or eventscan be performed concurrently, e.g., through multi-threaded processing,interrupt processing, or multiple processors or processor cores or onother parallel architectures, rather than sequentially.

The various illustrative logical blocks, modules, routines, andalgorithm steps described in connection with the embodiments disclosedherein can be implemented as electronic hardware, or as a combination ofelectronic hardware and executable software. To clearly illustrate thisinterchangeability, various illustrative components, blocks, modules,and steps have been described above generally in terms of theirfunctionality. Whether such functionality is implemented as hardware, oras software that runs on hardware, depends upon the particularapplication and design constraints imposed on the overall system. Thedescribed functionality can be implemented in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the disclosure.

Moreover, the various illustrative logical blocks and modules describedin connection with the embodiments disclosed herein can be implementedor performed by a machine, such as a general purpose processor device, adigital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic device, discrete gate or transistor logic, discretehardware components, or any combination thereof designed to perform thefunctions described herein. A general purpose processor device can be amicroprocessor, but in the alternative, the processor device can be acontroller, microcontroller, or state machine, combinations of the same,or the like. A processor device can include electrical circuitryconfigured to process computer-executable instructions. In anotherembodiment, a processor device includes an FPGA or other programmabledevice that performs logic operations without processingcomputer-executable instructions. A processor device can also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration. Although described herein primarily with respect todigital technology, a processor device may also include primarily analogcomponents. For example, some or all of the signal processing algorithmsdescribed herein may be implemented in analog circuitry or mixed analogand digital circuitry. A computing environment can include any type ofcomputer system, including, but not limited to, a computer system basedon a microprocessor, a mainframe computer, a digital signal processor, aportable computing device, a device controller, or a computationalengine within an appliance, to name a few.

The elements of a method, process, routine, or algorithm described inconnection with the embodiments disclosed herein can be embodieddirectly in hardware, in a software module executed by a processordevice, or in a combination of the two. A software module can reside inRAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory,registers, hard disk, a removable disk, a CD-ROM, or any other form of anon-transitory computer-readable storage medium. An exemplary storagemedium can be coupled to the processor device such that the processordevice can read information from, and write information to, the storagemedium. In the alternative, the storage medium can be integral to theprocessor device. The processor device and the storage medium can residein an ASIC. The ASIC can reside in a user terminal. In the alternative,the processor device and the storage medium can reside as discretecomponents in a user terminal.

For example, the process 300 described with respect to FIG. 3 may beembodied in a set of executable program instructions stored on one ormore non-transitory computer-readable media, such as one or more diskdrives or solid-state memory devices, of a computing system with whichthe computing service provider 104 is associated. When the process 300is initiated, the executable program instructions can be loaded intomemory, such as RAM, and executed by one or more processors of thecomputing system. In some embodiments, the computing system may includemultiple computing devices, such as servers, and the process or portionsthereof may be executed by multiple servers, serially or in parallel.

Conditional language used herein, such as, among others, “can,” “could,”“might,” “may,” “e.g.,” and the like, unless specifically statedotherwise, or otherwise understood within the context as used, isgenerally intended to convey that certain embodiments include, whileother embodiments do not include, certain features, elements and/orsteps. Thus, such conditional language is not generally intended toimply that features, elements and/or steps are in any way required forone or more embodiments or that one or more embodiments necessarilyinclude logic for deciding, with or without other input or prompting,whether these features, elements and/or steps are included or are to beperformed in any particular embodiment. The terms “comprising,”“including,” “having,” and the like are synonymous and are usedinclusively, in an open-ended fashion, and do not exclude additionalelements, features, acts, operations, and so forth. Also, the term “or”is used in its inclusive sense (and not in its exclusive sense) so thatwhen used, for example, to connect a list of elements, the term “or”means one, some, or all of the elements in the list.

Disjunctive language such as the phrase “at least one of X, Y, Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z).Thus, such disjunctive language is not generally intended to, and shouldnot, imply that certain embodiments require at least one of X, at leastone of Y, or at least one of Z to each be present.

Unless otherwise explicitly stated, articles such as “a” or “an” shouldgenerally be interpreted to include one or more described items.Accordingly, phrases such as “a device configured to” are intended toinclude one or more recited devices. Such one or more recited devicescan also be collectively configured to carry out the stated recitations.For example, “a processor configured to carry out recitations A, B andC” can include a first processor configured to carry out recitation Aworking in conjunction with a second processor configured to carry outrecitations B and C.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it can beunderstood that various omissions, substitutions, and changes in theform and details of the devices or algorithms illustrated can be madewithout departing from the spirit of the disclosure. As can berecognized, certain embodiments described herein can be embodied withina form that does not provide all of the features and benefits set forthherein, as some features can be used or practiced separately fromothers. The scope of certain embodiments disclosed herein is indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed is:
 1. A directory management system comprising one ormore physical computing devices programmed with executable instructionsto implement a process comprising: receiving directory accessconfiguration information for a directory, the directory accessconfiguration information including application access policyinformation for accessing the directory; determining, for a firstapplication, based on the received access configuration information, afirst policy regarding accessing the directory; responding to a requestfrom the first application to perform a first action on the directory bydetermining, based on the first policy, whether the first action isauthorized, and when the first action is authorized, by performing thefirst action on the directory on behalf of the first application;determining, for a second application, based on the received accessconfiguration information, a second policy regarding accessing thedirectory, wherein the second policy is different than the first policy;and responding to a request from the second application to perform asecond action on the directory by determining, based on the secondpolicy, whether the second action is authorized, and when the secondaction is authorized, by performing the second action on the directoryon behalf of the second application.
 2. The system of claim 1, whereinthe directory management system comprises a directory management userinterface that includes functionality for a provider of the directory toseparately specify, for at least the first and second applications,permissions for accessing the directory.
 3. The system of claim 1,wherein the directory is hosted remotely from the directory managementsystem, and the access configuration information includes a networkaddress of the directory.
 4. The system of claim 3, wherein the accessconfiguration information additionally includes user accountinformation, the user account information including permissions thatspecify actions the directory management system is authorized to performon the directory on behalf of applications.
 5. The system of claim 4,wherein the directory management system is configured to determinewhether the first action is authorized based on said permissions andbased additionally on the first policy.
 6. The system of claim 3,wherein the directory management system performs the first and secondactions on the directory using a user account created for the directorymanagement system.
 7. The system of claim 1, wherein the directorymanagement system receives said requests from the first and secondapplications via an application programming interface of the directorymanagement system.
 8. The system of claim 1, wherein each of the firstand second actions modifies contents of the directory.
 9. The system ofclaim 1, wherein the directory management system controls access by atleast the first and second applications to each of a plurality ofdirectories of each of a plurality of respective organizations, andincludes a directory management user interface that enables eachorganization to separately specify, for at least the first and secondapplications, operations that can be performed by the first and secondapplications on a directory of the respective organization.
 10. Acomputing system that hosts a directory management service, thecomputing system comprising one or more computing devices and beingprogrammed to provide at least: a directory management user interfacethat includes functionality for an owner of a directory to separatelyspecify, for each of a plurality of applications, permissions of theapplications to perform operations on the directory, includingoperations that modify contents of the directory; and a data repositorythat stores application access data for each of a plurality ofdirectories of each of a plurality of organizations, said applicationaccess data specified by the organizations for their respectivedirectories via the directory management user interface; wherein thecomputing system is programmed to respond to a request from anapplication to perform on operation on a first directory of a firstorganization by using at least the application access data of theorganization to determine whether the operation is authorized, and whenthe operation is authorized, by performing the operation on the firstdirectory on behalf of the application, said operation modifyingcontents of the first directory.
 11. The computing system of claim 10,wherein the first directory is hosted externally to the computingsystem.
 12. The computing system of claim 10, wherein the application ishosted externally to the computing system, and makes the request usingan application programming interface of the directory managementservice.
 13. The computing system of claim 10, wherein the computingsystem is programmed to perform the operation on the first directoryusing a user account that includes permissions that specify actions thedirectory management service is authorized to perform on the firstdirectory on behalf of applications.
 14. The computing system of claim10, wherein the computing system is programmed to determine whether theoperation is authorized based additionally on access rights of a userthat invokes the first application.
 15. The computing system of claim10, wherein the first directory comprises a collection of data regardinga plurality of resources of a computing network of the firstorganization, and at least a portion of the data is organized intoobjects representing individual resources of the plurality of resources.16. A method of controlling access by applications to a directory of anorganization, the method comprising, by a computing system that hosts adirectory management service: receiving directory access configurationinformation for a directory of an organization, the directory accessconfiguration information submitted via a user interface of thedirectory management service, the directory access informationseparately specifying, for each of a plurality of applications,permissions for performing operations on the directory; receiving, froma first application of the plurality of applications, a request toperform on operation on the directory of the organization, the operationcomprising a modification to contents of the directory; in response tothe request, determining, based at least in part on said permissions,whether the operation is authorized; and in response to determining thatthe operation is authorized, performing the operation on the directoryon behalf of the first application.
 17. The method of claim 16, whereinthe directory is hosted externally to the computing system.
 18. Themethod of claim 16, wherein the first application is hosted externallyto the computing system, and the request is submitted to the computingsystem via an application programming interface of the directorymanagement service.
 19. The method of claim 16, wherein thedetermination of whether the operation is authorized is basedadditionally on access rights of a user that invokes the firstapplication
 20. The method of claim 16, wherein performing the operationon the directory on behalf of the first application comprises using auser account to perform the operation, the user account assigned to thedirectory management service by the organization